(ARC310) Python WEBアプリの障害検知してみた

(ARC310) Python WEBアプリの障害検知してみた

re:Invent 2023のセッションARC310 Detecting and mitigating gray failuresで紹介されていたEMFによるメトリクスの作成、複合アラームによる部分的な障害検出をサンプルアプリで試してみました。
Clock Icon2023.12.26

はじめに

前回の記事に続いてサンプルアプリの障害検知をしてみます。 今回はメトリクスに対してアラームを作成し、レイテンシの注入によって発生する障害を検知します。

アラームの作成

各A/ZにプロビジョニングされるAPIを対象に以下のアラームを作成します。

  • 各A/Zのフロントエンドからバックエンドの接続性
    • health-1a: A/Z 1aでエラーが発生しているタスク数が 2個以上の場合
    • health-1c: A/Z 1cでエラーが発生しているタスク数が 2個以上の場合
    • health-1d: A/Z 1dでエラーが発生しているタスク数が 2個以上の場合
  • 各A/Zのバックエンドのレイテンシ
    • az1a-high-latency: BackendLantecy > 0.5 の場合
    • az1c-high-latency: BackendLantecy > 0.5 の場合
    • az1d-high-latency: BackendLantecy > 0.5 の場合

ここでhealth-1*はContributor Insightを使います。詳細は後述します。

これらを含む以下の複合アラームを作成します。

  • az-1a-failure: health-1a AND az1a-high-latency
  • az-1c-failure: health-1c AND az1c-high-latency
  • az-1d-failure: health-1d AND az1d-high-latency

これでA/Zごとの障害を検出するアラームができました。 最後にA/Z単独での障害を検出するアラームを作成します。

  • az1a-isolated-failure: az-1a-failure AND NOT (az-1c-failure OR az-1d-failure)
  • az1c-isolated-failure: az-1c-failure AND NOT (az-1a-failure OR az-1c-failure)
  • az1d-isolated-failure: az-1d-failure AND NOT (az-1a-failure OR az-1d-failure)

ヘルスチェックメトリクス(health-1*)

上記のアラームhealth-1*はContributor Insight で以下のようなルールを作成します。 Contribution.Filters内のAvailabilityZoneの値を各A/Zに変更したルールを3つ作成します。ロググループgray-failure-emfには前回セットアップしたEMFログが送信されています。

{
	"AggregateOn": "Count",
	"Contribution": {
		"Filters": [
			{
				"Match": "$.BackendHealth",
				"GreaterThan": 0
			},
			{
				"Match": "$.AvailabilityZone",
				"In": [
					"ap-northeast-1a"
				]
			}
		],
		"Keys": [
			"$.DockerId"
		]
	},
	"LogFormat": "JSON",
	"Schema": {
		"Name": "CloudWatchLogRule",
		"Version": 1
	},
	"LogGroupARNs": [
		"arn:aws:logs:ap-northeast-1:123456789000:log-group:gray-failure-emf"
	]
}

このルールをアラームでメトリクスとして参照するには以下のような式を指定します。

INSIGHT_RULE_METRIC("backend-health-1a", "UniqueContributors")

検証

準備ができたのでレイテンシを注入してアラームを試してみます。 

A/Z 1c だけレイテンシ増加

パラメータストアにレイテンシを設定してしばらくするとダッシュボードのアラームリストでA/Z 1cに関するアラームだけがアラーム状態になりました。1 A/Zだけの障害なのでaz1c-isolated-failureもアラーム状態になっています。

2 A/Zでレイテンシ増加

続いて2つめのA/Z 1dにもレイテンシを注入してみます。 1dに関するアラームがアラーム状態になりました。2A/Z以上の障害なのでaz1c-isolated-failureはアラーム状態ではなくなりました。

まとめ

EMFとContributor Insightを使ってA/Zごとの正常性を検出するアラームを作成し、一部のA/Zの障害を検出する複合アラームを作成、検証しました。 作り込みは必要でしたがメトリクスとログが準備できれば望む粒度で監視が行えることがわかりました。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.